home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 201 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.2 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c
  4. Subject: Re: Hungarian notation
  5. Date: 27 Jan 1996 03:18:15 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4ecqkn$p1t@solutions.solon.com>
  8. References: <30C40F77.53B5@swsbbs.com> <JSA.96Jan26175507@organon.com> <31098190.8106176@nntp.ix.netcom.com> <4eco1g$aih@fountain.mindlink.net>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <4eco1g$aih@fountain.mindlink.net>,
  12. Gene Wirchenko <genew@mindlink.bc.ca> wrote:
  13. >>I claim that ISO 6.2.1.2 requires that an implementation actually do
  14. >>such a conversion.  The implementor may choose the mapping.  Beside
  15. >>the usual throwing away of high order bits, possibilities include
  16. >>always using the value 0, or the largest possible value for the new
  17. >>type, or, even, a random value.
  18.  
  19. >     Implementation defined means implementation defined, not what you
  20. >want it to mean.  I agree that your interpretation sets out reasonable
  21. >actions that might be performed.  Please quote chapter and verse on
  22. >where the Standard states that implementation defined actions must be
  23. >"reasonable" (whatever the hell that is <G>).
  24.  
  25. Ahh, but there is the key.
  26.  
  27. My understanding (and I believe this is Mike's point) is that there is
  28. a different between implementation defined *BEHAVIOR* and an implementation
  29. defined *RESULT*.
  30.  
  31. My understanding is that integer conversions are an implementation
  32. defined *RESULT*.  No other *behavior* is allowed - the semantics do
  33. not imply or show any.
  34.  
  35. This is as opposed to system(), which has implementation defined *behavior*
  36. whenever system(NULL) returns non-zero.  In particular, an implementation
  37. could provide a command interpreter that interpreted any string as the string
  38. to write at the beginning of every block on a disk.  Such an implementation
  39. would likely do poorly in the marketplace (unless Microsoft marketed it as
  40. a new redundant filesystem), but would be legal.
  41.  
  42. However, given something where the *result* is implementation defined, I
  43. would expect that no unexpected *behavior* was allowed.
  44.  
  45. This is similar to the special case where a failure to return a value from
  46. main() results in an undefined *termination status* but is otherwise required
  47. to behave sanely; streams must be flushed, et al.  (Another ghastly thing
  48. in Schildt's C:TCR.  He says that fflush will clear the input buffer on
  49. input streams.  *sigh*.)
  50.  
  51. >     Is your claim supported in the Standard?  If it isn't, you're
  52. >wasting your time.  What if the conversion results in overflow?
  53.  
  54. The point of explicitly stating that the *result* is imp-defined is to
  55. *define the behavior*.
  56.  
  57. Note that Appendix G states (wrongly) that a conversion that could overflow
  58. results in undefined behavior.  This is only true of floating point ->
  59. integral conversions.  (It is also true of operations other than
  60. conversions.)
  61.  
  62. >     Why are no side effects permitted?  Chapter and verse, please.
  63.  
  64. Because none are specified.  The semantics of the >> operator on signed
  65. ints are implementation specified (or is that defined?) but no one would
  66. tolerate it formatting disks, because it doesn't say it can, and the
  67. wording makes it clear that no extra behavior is expected.
  68.  
  69. >     What if the conversion results in overflow?
  70.  
  71. This is actually a legitimate question; if conversion is taken to be
  72. an operation, then the previously pointed out limit on all arithmetic
  73. ops comes into play, and we have full-fleged *undefined behavior* -
  74. easily enough to format a disk with.
  75.  
  76. >     If it is impossible to convert due to sizing, then the "must" is
  77. >rather silly, isn't it?
  78.  
  79. Not really; it must do *some* conversion, and the conversion must be the
  80. obvious one where that applies, and implementation-defined elsewhere.
  81.  
  82. >Right Hand of God.  So what about your claims!  If they can't be
  83. >supported by the Standard, forget it.  Schildt CLAIMS that void main()
  84. >is ok.
  85.  
  86. Sadly, I am beginning to doubt that there is a true statement about C he
  87. *doesn't* deny somewhere in that book.
  88.  
  89. -s
  90. -- 
  91. Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach.
  92. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  93. Using trn?  Weird new newsgroup problem?  I know the fix!  Email me!
  94. The *other* C FAQ - ftp taniemarie.solon.com /pub/c/afq - Not A Flying Toy
  95.